The technology described herein relates to graphics processing, and in particular to the operation of graphics processing pipelines that perform vertex shading.
Graphics processing is normally carried out by first splitting a scene (e.g. a 3-D model) to be displayed into a number of similar basic components or “primitives”, which primitives are then subjected to the desired graphics processing operations. The graphics “primitives” are usually in the form of simple polygons, such as triangles.
Each primitive is usually defined by and represented as a set of vertices, where each vertex typically has associated with it a set of “attributes”, i.e. a set of data values for the vertex. These attributes will typically include position data and other, non-position data (varyings), e.g. defining colour, light, normal, texture coordinates, etc, for the vertex in question.
For a given output, e.g. frame to be displayed, to be generated by the graphics processing system, there will typically be a set of vertices defined for the output in question. The primitives to be processed for the output will then be indicated as comprising given vertices in the set of vertices for the graphics processing output being generated. Typically, the overall output, e.g. frame to be generated, will be divided into smaller units of processing, referred to as “draw calls”. Each draw call will have a respective set of vertices defined for it and a set of primitives that use those vertices.
Once primitives and their vertices have been generated and defined, they can be processed by the graphics processing system, in order to generate the desired graphics processing output (render target), such as a frame for display. This basically involves rasterising and rendering the primitives to generate the graphics processing output.
The rasterising and rendering processes use the vertex attributes associated with the vertices of the primitives that are being processed. To facilitate this operation, the attributes of the vertices defined for the given graphics processing output (e.g. draw call) are usually subjected to an initial so-called “vertex shading” operation, before the primitives are rasterised and rendered. This “vertex shading” operation operates to transform the attributes for each vertex into a desired form for the subsequent graphics processing operations. This may comprise, for example, transforming vertex position attributes from the world or user space that they are initially defined for to the screen space that the output of the graphics processing system is to be displayed in.
A graphics processing pipeline will typically therefore include a vertex shading stage (a vertex shader) that executes vertex shading computations on the initial vertex attribute values defined for the vertices so as to generate a desired set of output vertex attributes (i.e. appropriately “shaded” attributes) for use in subsequent processing stages of the graphics processing pipeline.
Once the vertex attributes have been shaded, the “shaded” attributes are then used when processing the vertices (and the primitives to which they relate) in the remainder of the graphics processing pipeline.
(In general “input variables” and “output variables” are the generic terms used for inputs and outputs from shaders (shading stages) in graphics processing pipelines. Before being vertex shaded, a vertex is a collection of “generic vertex attributes” that can be accessed within the vertex shader as input variables. The vertex shader execution then produces a vertex position and any outputs explicitly written by the vertex shader. “Varyings” are the attributes communicated from the vertex shader to rasterisation and fragment shading, not including position. (Thus only the non-position outputs from the vertex shader are “varyings”.))
One form of graphics processing pipeline is a so called tile-based graphics processing pipeline, wherein the two-dimensional render output or target is rendered as a plurality of smaller area sub-regions, usually referred to as “tiles”. The tiles are each rendered separately (typically one after another). The rendered tiles are then combined to provide the complete rendering output (e.g. frame for display).
(Other terms that are commonly used for “tiling” and “tile-based” rendering include “chunking” (the rendering tiles are referred to as “chunks”) and “bucket” rendering. The terms “tile” and “tiling” will be used hereinafter for convenience, but it should be understood that these terms are intended to encompass all alternative and equivalent terms and techniques.)
In a tile-based graphics processing pipeline, the geometry (primitives) for the render output being generated is sorted into the tiles that the rendering process operates on. The tiling process identifies primitives that need to be processed for a given rendering tile (so as to, e.g., avoid unnecessarily rendering primitives that are not actually present in a tile). The tiling process produces lists of primitives to be rendered for the rendering tiles. Then, once the primitive lists have been prepared for the rendering tiles, each rendering tile is processed, by rasterising and rendering the primitives listed for the rendering tile.
An important aspect of tile-based graphics processing therefore is the initial processing to generate the primitive lists for use to identify the primitives that need to be processed for the rendering tiles, which initial processing is then followed by the main rasterising and rendering passes for the tiles.
Thus, in a tile-based processing system there will be an initial processing pass which, in effect, sorts the graphics primitives (and/or other graphics entities) to be processed into the tiles that the render output is divided into for processing purposes. This initial processing pass must be performed for all the geometry (primitives), etc., for the render output unit of processing (e.g. draw call) to be processed (as it is only once all the geometry has been sorted into the “tiles” that all the geometry that needs to be processed for a given tile will be known). The rasterising and rendering of the geometry (primitives) in the tiles to generate the render output can accordingly only be done once the initial processing to sort the geometry, etc. into the tiles has been completed, and so, is, in effect, “deferred” until the initial processing of the geometry (primitives) to sort it into the tiles has been completed.
Tile-based graphics processing pipelines can accordingly be thought of as (and referred to as) “deferred” graphics processing pipelines (graphics processors) (and to perform “deferred” rendering). This is because the rasterising and rendering pass is deferred until suitable lists of primitives to be processed have been prepared for each tile that the render output has been divided into for processing purposes.
The Applicants have recognised that when performing deferred rendering as in the case of a tile-based graphics processing pipeline, it is desirable to retain (store) geometry data (and in particular vertex-shaded vertex data) that has been used for the initial “tiling” processing pass for use in the later deferred rasterising and rendering pass. This can then avoid, e.g., having to re-generate the vertex-shaded vertex data (to “re-shade” vertices) between the initial “tiling” processing pass and the later deferred rasterising and rendering pass.
However, this then means that there is a need to store geometry (and in particular vertex) data for a period of time for use in the later, deferred, rasterising and rendering pass. Accordingly, memory needs to be allocated to store this data so that it is available for the later deferred rasterising and rendering pass.
One way to do this would simply be to allocate the maximum amount of memory space that could possibly be required for all of the geometry (vertex) data (potentially) to be processed (e.g. based on the total number of vertices input by the application that requires the graphics processing). However, this can be inefficient in terms of the overall usage of memory in the data processing system that the graphics processing pipeline is part of (or, indeed, there may not be sufficient available memory space to set aside for all of the (potentially) required data). It can also be a relatively complex task to determine how much memory space should be allocated.
It would also be possible to use more complex analysis of the likely memory storage requirements so as to try to achieve more efficient allocation of memory for this purpose, but this can lead to increased driver complexity and operations (and/or may require some or all of the “memory allocation” operations to be performed on the graphics processor itself).
The Applicants accordingly believe that there remains scope for improvements to, in particular tile-based, graphics processing pipelines that employ vertex shading.
Like reference numerals are used for like components in the Figures, where appropriate.